home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 2001 May / SGI Freeware 2001 May - Disc 3.iso / dist / fw_apache.idb / usr / freeware / apache / include / http_main.h.z / http_main.h
Encoding:
C/C++ Source or Header  |  2001-01-10  |  7.9 KB  |  181 lines
  1. /* ====================================================================
  2.  * Copyright (c) 1995-1999 The Apache Group.  All rights reserved.
  3.  *
  4.  * Redistribution and use in source and binary forms, with or without
  5.  * modification, are permitted provided that the following conditions
  6.  * are met:
  7.  *
  8.  * 1. Redistributions of source code must retain the above copyright
  9.  *    notice, this list of conditions and the following disclaimer. 
  10.  *
  11.  * 2. Redistributions in binary form must reproduce the above copyright
  12.  *    notice, this list of conditions and the following disclaimer in
  13.  *    the documentation and/or other materials provided with the
  14.  *    distribution.
  15.  *
  16.  * 3. All advertising materials mentioning features or use of this
  17.  *    software must display the following acknowledgment:
  18.  *    "This product includes software developed by the Apache Group
  19.  *    for use in the Apache HTTP server project (http://www.apache.org/)."
  20.  *
  21.  * 4. The names "Apache Server" and "Apache Group" must not be used to
  22.  *    endorse or promote products derived from this software without
  23.  *    prior written permission. For written permission, please contact
  24.  *    apache@apache.org.
  25.  *
  26.  * 5. Products derived from this software may not be called "Apache"
  27.  *    nor may "Apache" appear in their names without prior written
  28.  *    permission of the Apache Group.
  29.  *
  30.  * 6. Redistributions of any form whatsoever must retain the following
  31.  *    acknowledgment:
  32.  *    "This product includes software developed by the Apache Group
  33.  *    for use in the Apache HTTP server project (http://www.apache.org/)."
  34.  *
  35.  * THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY
  36.  * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  37.  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  38.  * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE APACHE GROUP OR
  39.  * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  40.  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  41.  * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  42.  * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  43.  * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  44.  * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  45.  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  46.  * OF THE POSSIBILITY OF SUCH DAMAGE.
  47.  * ====================================================================
  48.  *
  49.  * This software consists of voluntary contributions made by many
  50.  * individuals on behalf of the Apache Group and was originally based
  51.  * on public domain software written at the National Center for
  52.  * Supercomputing Applications, University of Illinois, Urbana-Champaign.
  53.  * For more information on the Apache Group and the Apache HTTP server
  54.  * project, please see <http://www.apache.org/>.
  55.  *
  56.  */
  57.  
  58. #ifndef APACHE_HTTP_MAIN_H
  59. #define APACHE_HTTP_MAIN_H
  60.  
  61. #ifdef __cplusplus
  62. extern "C" {
  63. #endif
  64.  
  65. /*
  66.  * Routines in http_main.c which other code --- in particular modules ---
  67.  * may want to call.  Right now, that's limited to timeout handling.
  68.  * There are two functions which modules can call to trigger a timeout
  69.  * (with the per-virtual-server timeout duration); these are hard_timeout
  70.  * and soft_timeout.
  71.  *
  72.  * The difference between the two is what happens when the timeout
  73.  * expires (or earlier than that, if the client connection aborts) ---
  74.  * a soft_timeout just puts the connection to the client in an
  75.  * "aborted" state, which will cause http_protocol.c to stop trying to
  76.  * talk to the client, but otherwise allows the code to continue normally.
  77.  * hard_timeout(), by contrast, logs the request, and then aborts it
  78.  * completely --- longjmp()ing out to the accept() loop in http_main.
  79.  * Any resources tied into the request's resource pool will be cleaned up;
  80.  * everything that isn't will leak.
  81.  *
  82.  * soft_timeout() is recommended as a general rule, because it gives your
  83.  * code a chance to clean up.  However, hard_timeout() may be the most
  84.  * convenient way of dealing with timeouts waiting for some external
  85.  * resource other than the client, if you can live with the restrictions.
  86.  *
  87.  * (When a hard timeout is in scope, critical sections can be guarded
  88.  * with block_alarms() and unblock_alarms() --- these are declared in
  89.  * alloc.c because they are most often used in conjunction with
  90.  * routines to allocate something or other, to make sure that the
  91.  * cleanup does get registered before any alarm is allowed to happen
  92.  * which might require it to be cleaned up; they * are, however,
  93.  * implemented in http_main.c).
  94.  *
  95.  * NOTE!  It's not "fair" for a hard_timeout to be in scope through calls
  96.  * across modules.  Your module code really has no idea what other modules may
  97.  * be present in the server, and they may not take too kindly to having a
  98.  * longjmp() happen -- it could result in corrupted state.  Heck they may not
  99.  * even take to kindly to a soft_timeout()... because it can cause EINTR to
  100.  * happen on pretty much any syscall, and unless all the libraries and modules
  101.  * in use are known to deal well with EINTR it could cause corruption as well.
  102.  * But things are likely to do much better with a soft_timeout in scope than a
  103.  * hard_timeout.
  104.  * 
  105.  * A module MAY NOT use a hard_timeout() across * sub_req_lookup_xxx()
  106.  * functions, or across run_sub_request() functions.  A module SHOULD NOT use a
  107.  * soft_timeout() in either of these cases, but sometimes there's just no
  108.  * choice.
  109.  *
  110.  * kill_timeout() will disarm either variety of timeout.
  111.  *
  112.  * reset_timeout() resets the timeout in progress.
  113.  */
  114.  
  115. API_EXPORT(void) ap_start_shutdown(void);
  116. API_EXPORT(void) ap_start_restart(int);
  117. API_EXPORT(void) ap_hard_timeout(char *, request_rec *);
  118. void ap_keepalive_timeout(char *, request_rec *);
  119. API_EXPORT(void) ap_soft_timeout(char *, request_rec *);
  120. API_EXPORT(void) ap_kill_timeout(request_rec *);
  121. API_EXPORT(void) ap_reset_timeout(request_rec *);
  122.  
  123. API_EXPORT(void) ap_child_terminate(request_rec *r);
  124. API_EXPORT(void) ap_sync_scoreboard_image(void);
  125. int ap_update_child_status(int child_num, int status, request_rec *r);
  126. void ap_time_process_request(int child_num, int status);
  127. #ifdef EAPI
  128. API_EXPORT(unsigned int) ap_set_callback_and_alarm(void (*fn) (int), int x);
  129. #else
  130. unsigned int ap_set_callback_and_alarm(void (*fn) (int), int x);
  131. #endif
  132. API_EXPORT(int) ap_check_alarm(void);
  133.  
  134. void setup_signal_names(char *prefix);
  135.  
  136. #ifndef NO_OTHER_CHILD
  137. /*
  138.  * register an other_child -- a child which the main loop keeps track of
  139.  * and knows it is different than the rest of the scoreboard.
  140.  *
  141.  * pid is the pid of the child.
  142.  *
  143.  * maintenance is a function that is invoked with a reason, the data
  144.  * pointer passed here, and when appropriate a status result from waitpid().
  145.  *
  146.  * write_fd is an fd that is probed for writing by select() if it is ever
  147.  * unwritable, then maintenance is invoked with reason OC_REASON_UNWRITABLE.
  148.  * This is useful for log pipe children, to know when they've blocked.  To
  149.  * disable this feature, use -1 for write_fd.
  150.  */
  151. API_EXPORT(void) ap_register_other_child(int pid,
  152.        void (*maintenance) (int reason, void *data, ap_wait_t status), void *data,
  153.                       int write_fd);
  154. #define OC_REASON_DEATH        0    /* child has died, caller must call
  155.                      * unregister still */
  156. #define OC_REASON_UNWRITABLE    1    /* write_fd is unwritable */
  157. #define OC_REASON_RESTART    2    /* a restart is occuring, perform
  158.                      * any necessary cleanup (including
  159.                      * sending a special signal to child)
  160.                      */
  161. #define OC_REASON_UNREGISTER    3    /* unregister has been called, do
  162.                      * whatever is necessary (including
  163.                      * kill the child) */
  164. #define OC_REASON_LOST        4    /* somehow the child exited without
  165.                      * us knowing ... buggy os? */
  166.  
  167. /*
  168.  * unregister an other_child.  Note that the data pointer is used here, and
  169.  * is assumed to be unique per other_child.  This is because the pid and
  170.  * write_fd are possibly killed off separately.
  171.  */
  172. API_EXPORT(void) ap_unregister_other_child(void *data);
  173.  
  174. #endif
  175.  
  176. #ifdef __cplusplus
  177. }
  178. #endif
  179.  
  180. #endif    /* !APACHE_HTTP_MAIN_H */
  181.